This server lets AI assistants directly control and inspect 2021 Roblox Studio / Aisaka Studio through MCP.
Capture screenshots of the Studio window for visual inspection.
Execute arbitrary Luau code in edit mode with undo checkpoints.
Read and overwrite the source of scripts, local scripts, and module scripts.
Explore the DataModel hierarchy with configurable depth.
Create and delete instances with custom properties.
Retrieve recent Studio output/console messages.
Search across all scripts with script_grep.
Inspect detailed properties, children, attributes, and tags of instances.
Audit 3D scene assets for external asset IDs.
Start, stop, and run automated playtests with screenshot capture.
Provides tools for interacting with 2021 Roblox Studio / Aisaka Studio, enabling AI agents to capture viewport screenshots, execute Luau code, read and write scripts, explore the DataModel hierarchy, create and delete instances, and retrieve Studio output logs.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@2021 Roblox Studio MCP Bridge take a screenshot of my Roblox Studio window"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Connect AI coding assistants (OpenCode, Claude Desktop / Claude Code, Cursor, Codex, Windsurf, Gemini CLI) directly to 2021 Roblox Studio / Aisaka Studio using Anthropic's Model Context Protocol (MCP).
screen_capture: Captures a screenshot of the 2021 Roblox Studio / Aisaka window directly into the AI's chat context so vision models can see your viewport, models, and GUIs!
execute_luau: Executes arbitrary Luau code in edit mode with automatic ChangeHistoryService undo checkpoints.
read_script & write_script: Reads and overwrites the complete source code of scripts, local scripts, and module scripts.
get_tree: Explores the DataModel hierarchy (Workspace, StarterGui, ServerScriptService, etc.).
create_instance & delete_instance: Creates parts, models, or GUIs with custom properties, or deletes objects.
get_output_log: Retrieves recent console messages from Studio.
Related MCP server: Roblox Studio MCP
Open Windows Run (Win + R), type:
%localappdata%\Roblox\Pluginsand press Enter.
Copy MCPBridge2021.lua into that folder.
Open 2021 Roblox Studio.
Go to Game Settings > Security and turn ON Allow HTTP Requests (or run game:GetService("HttpService").HttpEnabled = true in the Command Bar).
Check your Output window in Studio; you should see:
[MCP 2021] Bridge initialized. Connecting to http://127.0.0.1:3021 ...Open your terminal (PowerShell or Command Prompt) in the repository folder and run:
npm installAdd this to opencode.json (or ~/.config/opencode/opencode.jsonc):
{
"$schema": "https://opencode.ai/config.json",
"mcp": {
"Roblox_2021": {
"type": "local",
"command": ["node", "C:/path/to/server.js"],
"enabled": true
}
}
}Add this to %APPDATA%\Claude\claude_desktop_config.json:
{
"mcpServers": {
"roblox-2021": {
"command": "node",
"args": ["C:/path/to/server.js"]
}
}
}In your project folder, create .cursor/mcp.json (or add in Cursor Settings > Features > MCP):
{
"mcpServers": {
"roblox-2021": {
"command": "node",
"args": ["C:/path/to/server.js"]
}
}
}Run in your terminal:
codex mcp add roblox-2021 -- node "C:/path/to/server.js"Add to ~/.codeium/windsurf/mcp_config.json:
{
"mcpServers": {
"roblox-2021": {
"command": "node",
"args": ["C:/path/to/server.js"]
}
}
}Run in your terminal:
claude mcp add roblox-2021 -- node "C:/path/to/server.js"Tool | Description |
| Captures a high-resolution screenshot of the Studio window or active screen for visual AI inspection. |
| Executes arbitrary Luau code in Studio's edit context with undo waypoint tracking. |
| Traverses and returns the DataModel hierarchy ( |
| Reads the complete |
| Writes or overwrites the |
| Creates new instances ( |
| Destroys instances in the DataModel safely. |
| Retrieves recent output log messages from Studio. |
| Global search across all scripts in the place for matching text/regex lines. |
| Inspects detailed properties, children, attributes, and tags of any instance. |
| Scans all 3D scene objects (sounds, meshes, decals, particles, clothing) and reports external asset IDs. |
| Starts a playtest in Studio ( |
| Stops the active playtest simulation and returns to Edit mode (Shift+F5). |
| Autonomous AI test: launches test, monitors for console errors over N seconds, takes gameplay screenshot, and returns to Edit mode. |
MIT License
Creates a new Instance in the DataModel
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Name for the new instance | |
| parent | No | Parent path (e.g. 'game.Workspace') | game.Workspace |
| className | Yes | Class name of the instance (e.g. 'Part', 'Folder', 'Script') | |
| properties | No | Key-value dictionary of initial properties |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description carries the full behavioral burden, and it discloses very little. It does not say whether the instance is immediately visible in the tree, what happens if the className is invalid or the parent path does not exist, or whether the call requires specific permissions. 'Creates' is the only behavioral signal given.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single short sentence with no filler, and the verb/resource lead is front-loaded. It is efficient, though its brevity reflects under-specification rather than disciplined concision.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations, no output schema, and a nested 'properties' object, the description is too thin. It omits failure modes, return value, and whether the newly created instance is auto-parented when 'parent' is defaulted, leaving meaningful gaps for an agent invoking a state-changing operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (name, parent with default 'game.Workspace', className with examples, properties dictionary), so the schema already documents all four parameters. The description adds no parameter detail at all, making the baseline 3 appropriate rather than a penalty.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb+resource ('Creates a new Instance in the DataModel') that clearly distinguishes this write tool from siblings like get_tree, delete_instance, and read_script. It does not, however, name or differentiate against execute_luau, which can also instantiate objects, so it stops short of full sibling disambiguation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance is provided. It never states prerequisites (e.g. a valid parent must exist), nor does it mention that execute_luau is an alternative for instance creation. The agent is left to infer all routing logic from the one-line purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Deletes an instance from the DataModel
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Path of instance to destroy |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full disclosure burden, yet it only says the instance is deleted from the DataModel. It does not state whether deletion is recursive over children, whether it is reversible, what permissions are needed, or what happens if the path does not exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no filler; appropriately sized for a one-parameter tool, though its brevity reflects under-specification rather than true economy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive, unannotated operation with no output schema, the description omits return behavior, error conditions, and the recursive/permission semantics an agent needs. The complexity is low, but the destructive nature warrants more than one sentence.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single 'path' parameter is documented in the schema as 'Path of instance to destroy'. The description adds no format, syntax, or path-resolution detail beyond that, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Deletes) and resource (instance) plus scope (from the DataModel), which clearly separates it from write_script or create_instance. It does not explicitly name or contrast with any sibling, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this versus create_instance or write_script, no prerequisites, and no warning about the destructive nature of the operation. The agent must infer usage entirely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Executes Luau code in 2021 Roblox Studio edit context and returns output
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | Luau code to run in Studio |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. For an arbitrary code-execution tool it omits critical traits: whether execution is sandboxed, whether it can mutate the Studio document, permissions required, error/failure behavior, or runtime limits. It only says it runs in edit context and returns output.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single efficient sentence with the operation and context front-loaded. No wasted words, though it is arguably too terse given what it leaves unsaid.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a high-risk arbitrary-code-execution tool with no annotations and no output schema, the description is too thin. It should disclose side-effect potential, sandboxing/editing semantics, and output format expectations to be complete enough for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter and schema description coverage is 100%, so the schema already documents the code argument. The description adds no syntax, format, or size constraints beyond what the schema provides; baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Executes) and resource (Luau code) and pins the execution context (2021 Roblox Studio edit context) and that it returns output. This clearly distinguishes it as the only arbitrary-code-execution tool among siblings like read_script or create_instance, though it does not name those siblings explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this versus the more targeted siblings (read_script, write_script, create_instance, get_tree). An agent must infer that this is the escape hatch for operations the structured tools don't cover.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieves recent messages from Studio's output log
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum lines to retrieve (default: 50) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden and doesn't meet it. It doesn't say whether the log is consumed/cleared on read, the ordering of messages, how far back 'recent' reaches, or whether the call is side-effect free.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One short, front-loaded sentence with zero filler. The verb-and-resource structure is immediately parseable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a trivial one-optional-param read tool with full schema coverage, the description is minimally sufficient, but with no annotations and no output schema it could easily state ordering or recency semantics of the returned log lines.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the single 'limit' parameter is fully documented in the schema (type, default, meaning), so the description need not add more. Baseline 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Retrieves) and resource (Studio's output log), which is clearly distinguishable from siblings like read_script, get_tree, or execute_luau. It stops short of any explicit sibling differentiation, so a 4 rather than a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to reach for this tool versus alternatives, no note on prerequisites (e.g., that it reads console output rather than script source), and no exclusions. The agent must infer the usage context entirely.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scans and returns the hierarchy tree starting at root path
| Name | Required | Description | Default |
|---|---|---|---|
| root | No | Instance path (e.g. 'game.Workspace', 'game.ServerScriptService') | game.Workspace |
| maxDepth | No | Max recursive depth to traverse (default: 2) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. 'Scans' hints at a read operation, but there is no disclosure of cost/performance for large trees, the effect of maxDepth on what is returned, or whether the result is nested or flattened. This is a meaningful gap for a traversal tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no filler, and the scoping constraint is stated up front. It is efficient but arguably too terse to be fully useful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema and no annotations, so the description should explain the return shape (nested tree vs flat list) and depth behavior. Neither is covered, leaving the agent guessing at the result format for a tool whose output structure is non-obvious.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both root and maxDepth are already documented. The description only reinforces the root concept ('starting at root path') and adds nothing about maxDepth defaults or semantics. Baseline 3 applies when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a specific verb ('scans and returns') and resource ('hierarchy tree') scoped by a root path. An agent can tell it apart from read_script or get_output_log. However, it never names or contrasts any sibling, so the differentiation is inferred rather than stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this versus alternatives such as read_script or get_output_log, and no mention of prerequisites or when-not to use it. Usage is only implied by the purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reads the complete Source text of a Script, LocalScript, or ModuleScript
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Full instance path (e.g. 'game.ServerScriptService.MyScript') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. 'Reads' implies a non-mutating operation and 'complete' signals the full source is returned rather than a snippet, but permissions, failure behavior for invalid paths, and rate limits are unstated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no filler; every word (complete, Source, the three instance types) carries information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read tool with no output schema, the description conveys what is returned ('complete Source text') and which instance types apply, which is close to sufficient. Remaining gaps around path resolution and error cases are minor.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single path parameter is fully documented in the schema with a format example, so the description adds no parameter meaning beyond it. Baseline 3 applies when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Reads) and resource (the complete Source text) and scopes it to the three relevant script instance types. It implicitly contrasts with write_script, but it does not explicitly name a sibling to route the agent away from, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this versus siblings such as get_tree (which also exposes instance contents) or execute_luau. No prerequisites, exclusions, or situational context are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Captures a screenshot of the 2021 Roblox Studio / Aisaka window or active screen and returns it as an image for visual inspection
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full disclosure burden. It usefully reveals the return type ('as an image') for a tool with no output schema, but says nothing about capture resolution, image format, which window wins when 'Studio' and 'active screen' differ, or failure behavior when the window is absent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence that leads with the verb and result. It is efficient, though the hedged phrase '2021 Roblox Studio / Aisaka window or active screen' adds clutter without resolving the ambiguity it introduces.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with no output schema and no annotations, the description covers the essentials: what is captured and that an image is returned. The only real gap is which capture target is selected when multiple windows exist, which an agent may need to know.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so there is no parameter semantics to document and the description has nothing to compensate for. Baseline 4 applies per the zero-parameter rule.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Captures') and resource ('screenshot'), and the output ('returns it as an image'), which clearly separates it from siblings like get_tree or execute_luau. The qualifier '2021 Roblox Studio / Aisaka window or active screen' is oddly specific and leaves the exact capture target ambiguous, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'for visual inspection' implies the intent behind the tool, giving minimal but real usage context. It never states when to prefer this over alternatives such as get_tree or get_output_log, nor any conditions or prerequisites, so guidance is only implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Updates or overwrites the Source text of an existing Script in Studio
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Full instance path | |
| source | Yes | New source code for the script |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full disclosure burden. It does signal that existing source is 'overwritten' (implying no undo), but omits permissions/context requirements, behavior if the path is missing or not a Script, and whether the change takes effect while the game is running.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no filler; the mutation and its target are stated immediately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With only two well-documented params and no output schema, the core is covered. However, with zero annotations and no output schema, the description should clarify failure modes and required execution context, which it does not.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so 'Full instance path' and 'New source code for the script' are already documented. The description adds no syntax, format, or path-resolution detail beyond the schema, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('updates or overwrites') and resource ('Source text of an existing Script in Studio'), and the word 'existing' usefully signals it won't create a new script. It does not explicitly contrast with siblings like read_script or execute_luau, but the operation is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this over read_script or execute_luau, no prerequisites, and no note that the path must resolve to an existing Script rather than another instance type. The agent must infer all of this from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0create_instancedelete_instanceexecute_luauget_output_logget_treeread_scriptscreen_capturewrite_scriptScored across 8 tools
Most tools target clearly distinct operations (capture screen, read/write script, create/delete instance, scan tree, read log). The main overlap is execute_luau, which can perform the same effects as create_instance/delete_instance/write_script, blurring boundaries for an agent choosing an approach. Still, each tool has a reasonably clear primary purpose.
All tools follow a consistent snake_case verb_noun pattern (screen_capture, execute_luau, get_tree, delete_instance, read_script, write_script, create_instance, get_output_log). Verbs are predictable and resources are clearly named. No mixing of conventions.
Eight tools is well-scoped for a Roblox Studio bridge, covering visual, code, hierarchy, and lifecycle operations without bloat. Each tool earns its place and none appear redundant in count.
Core lifecycle is covered: create/delete instance, read/write script, inspect tree and logs, capture screen, and execute_luau as an escape hatch. However, there is no direct tool for updating instance properties, reparenting, or renaming, which agents must work around via execute_luau.
Use AI models for chat, image, and video generation from Claude Code and other MCP hosts.
Remote MCP server to read and manage your Atako AI agents, messages, files, and integrations.
Live browser debugging for AI assistants — DOM, console, network via MCP.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
