Skip to main content
Glama
EL4CTEO

Roblox Studio MCP

by EL4CTEO
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Local

Emulate a phone, tablet or console

device

Resize the Studio viewport to a real phone, tablet or console and throttle the network to expose mobile-only UI faults and lag bugs.

Instructions

Resizes the Studio viewport to a real device, so you can see what a player on that device sees.

Most Roblox players are on a phone and most UI is built on a desktop monitor, which is where interfaces break: a button under the notch, a menu off the bottom of a 393-pixel-tall screen, text sized for a display three times larger. None of that is visible in the data model — every one of those instances has perfectly correct properties — so this is the only way to find it short of owning the hardware.

The workflow is: set a device, screenshot, look. Pair it with playtest to check a running game's HUD rather than the editor.

list gives the ids, each with its real name, form factor and resolution — ids look like "iphone_16", "ipad_a16", "samsung_galaxy_s25_ultra", "xbox", "meta_quest_3".

network degrades the connection on purpose — latency, jitter and packet loss — which is the other half of what a phone player actually gets. A menu that works at 0ms is not evidence that it works at 300: the spinner that never stops, the button that fires twice, the HUD that arrives after the round started are all invisible on a local connection. Use a preset (wifi, 4g, 3g, poor, clear) or set the numbers yourself, then playtest and watch.

stop returns Studio to the normal editor viewport AND clears the network shaping. Do that when you are finished: a left-over emulated device makes every later screenshot the wrong shape, a left-over 400ms delay makes the whole place feel broken, and nothing on screen says why in either case.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
opNo'list' shows the available devices, 'set' switches to one, 'network' shapes the connection, 'stop' undoes both, 'state' only reports.state
formNolist only: show only devices of this form factor.
lossNonetwork only: percentage of packets thrown away, up to 50 — the engine's own ceiling. The field that finds real bugs: latency makes a game feel slow, loss makes it behave wrongly. 2-8% is a bad mobile connection.
deviceNoset only: the device id, e.g. "iphone_16". See `list`.
jitterNonetwork only: how much the delay varies, in milliseconds. Jitter breaks things steady latency does not — it is what makes replicated motion stutter rather than simply lag.
memoryNonetwork only: pretend the machine has this many MB of memory. A cheap phone is a small screen AND little memory; this is the half that makes textures unload. 0 removes the cap.
presetNonetwork only: a whole connection in one word. clear=0ms (normal), wifi=15ms, 4g=60ms/0.5% loss, 3g=150ms/2% loss, poor=400ms/8% loss. Named fields below override whichever part you name.
latencyNonetwork only: minimum delay in milliseconds, up to 1000 — the engine's own ceiling. 0 clears it.
studioIdNoTarget Studio; omit for the active one.
directionNonetwork only: which way to degrade. 'in' is the player with a bad connection, 'out' is everyone else seeing that player late. Defaults to both.
orientationNoset only: which way up. Portrait is worth testing separately — most mobile players hold the phone upright and most UI is only ever checked in landscape.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed8 schema fields changedv0.6.5
    • addedInput schema / properties / direction
      Added value: +{
+  "description": "network only: which way to degrade. 'in' is the player with a bad connection, 'out' is everyone else seeing that player late. Defaults to both.",
+  "enum": [
+    "in",
+    "out",
+    "both"
+  ],
+  "type": "string"
+}
    • addedInput schema / properties / jitter
      Added value: +{
+  "description": "network only: how much the delay varies, in milliseconds. Jitter breaks things steady latency does not — it is what makes replicated motion stutter rather than simply lag.",
+  "maximum": 1000,
+  "minimum": 0,
+  "type": "number"
+}
    • addedInput schema / properties / latency
      Added value: +{
+  "description": "network only: minimum delay in milliseconds, up to 1000 — the engine's own ceiling. 0 clears it.",
+  "maximum": 1000,
+  "minimum": 0,
+  "type": "number"
+}
    • addedInput schema / properties / loss
      Added value: +{
+  "description": "network only: percentage of packets thrown away, up to 50 — the engine's own ceiling. The field that finds real bugs: latency makes a game feel slow, loss makes it behave wrongly. 2-8% is a bad mobile connection.",
+  "maximum": 50,
+  "minimum": 0,
+  "type": "number"
+}
    • addedInput schema / properties / memory
      Added value: +{
+  "description": "network only: pretend the machine has this many MB of memory. A cheap phone is a small screen AND little memory; this is the half that makes textures unload. 0 removes the cap.",
+  "maximum": 65536,
+  "minimum": 0,
+  "type": "integer"
+}
    • changedInput schema / properties / op / description
      Previous value: -"'list' shows the available devices, 'set' switches to one, 'stop' returns to the normal viewport, 'state' only reports."New value: +"'list' shows the available devices, 'set' switches to one, 'network' shapes the connection, 'stop' undoes both, 'state' only reports."
    • changedInput schema / properties / op / enum
      Previous value: -[
-  "list",
-  "set",
-  "stop",
-  "state"
-]New value: +[
+  "list",
+  "set",
+  "network",
+  "stop",
+  "state"
+]
    • addedInput schema / properties / preset
      Added value: +{
+  "description": "network only: a whole connection in one word. clear=0ms (normal), wifi=15ms, 4g=60ms/0.5% loss, 3g=150ms/2% loss, poor=400ms/8% loss. Named fields below override whichever part you name.",
+  "enum": [
+    "clear",
+    "wifi",
+    "4g",
+    "3g",
+    "poor"
+  ],
+  "type": "string"
+}
  2. First observedv0.1.8

TDQS

A4.8/5.0
Behavior5/5

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

Beyond the annotations (readOnlyHint=false, destructiveHint=false), the description discloses serious behavioral traits: that stop also clears network shaping, that a left-over device silently corrupts every later screenshot, that a lingering 400ms delay makes everything feel broken, and that nothing on screen explains why. This is exactly the side-effect and cleanup context the annotations cannot convey.

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 core purpose is front-loaded and the paragraphs are cleanly separated by concern (motivation, workflow, list, network, stop). It is longer than average, with the 'Most Roblox players are on a phone' paragraph being expository, but the length is largely justified by 11 parameters and 5 operations.

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?

There is no output schema, and the description covers what an agent needs across all operations: set/list/network/stop behavior, cleanup requirements, and pairing with screenshot and playtest. The only op not explicitly narrated is 'state', which the schema itself defines as reporting-only.

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 already documents each field, making 3 the baseline. The description adds meaning on top: concrete device-id examples ('iphone_16', 'ipad_a16', 'samsung_galaxy_s25_ultra'), the framing of network shaping as deliberately degrading the connection, and the semantics of the presets and direction of degradation.

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: 'Resizes the Studio viewport to a real device, so you can see what a player on that device sees.' It further distinguishes itself from siblings by naming playtest and screenshot and clarifying that it operates on the editor viewport rather than a running game's HUD.

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?

It gives an explicit workflow ('set a device, screenshot, look'), states when to use it (finding device-specific UI breakage invisible in the data model), routes to alternatives ('Pair it with playtest to check a running game's HUD rather than the editor'), and states when to undo it ('stop... Do that when you are finished').

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