Loading ToolBench
MCP server for Roblox Studio. 35 tools, push-based SSE bridge, editor-safe script edits, one-step undo.
This server registers 29 tools but exhibits critical quality gaps across naming, descriptions, parameters, and schemas. While tool names generally follow verb_noun conventions (execute_luau, script_read, create, modify, delete), the majority lack adequate descriptions and complete input schemas. The server file organization is scattered (test-tools.mjs, individual tool files in src/tools/), and only partial schema definitions are visible in the provided code. Most tool descriptions are extremely brief (under 50 chars), many parameters lack descriptions entirely, and output schemas are not documented. Error handling is minimal, no recovery guidance visible. The code shows a sophisticated Roblox integration architecture, but the MCP tool interface quality does not meet production standards for agent usability.
Work with animation assets and playback
Query API documentation and member information
Manage audio assets and sound playback
Manage and configure character appearance and animations
Access and control the Studio console output and logging
Create new instances in the workspace
Manage DataStore and persistence operations
Debug remote function/event calls and analyze network traffic
13 of 29 tools have descriptions under 20 characters or are missing entirely, violating the critical requirement that every tool must have a non-empty description of 10-1024 characters to enable LLM selection.
Parameter descriptions are missing or extremely brief across most tools. The rubric requires EVERY parameter to have a non-empty description explaining what it controls, format, and valid values. Tools like 'viewport' (op, path), 'debug' (op, path, player, seconds), 'create', 'modify', 'move' lack adequate param guidance for LLM input generation.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 50 | 2026-07-28+ | v2 |
Delete instances from the workspace
Query device and environment information
Execute Luau code in Studio or on a connected player client
Generate procedural content and assets
Send input steps (clicks, key presses, text) to a connected player client
Inspect properties and details of instances
List all connected Studio windows and their place information
Modify properties of existing instances
Move or reparent instances to new locations
Profile performance metrics and analyze memory/CPU usage
Control playtest state (play, run, multiplayer, state transitions)
Capture a screenshot from Studio or playtest viewport
Edit script source code with automated transformations
Read the source code of scripts or modules
Set which Studio window is the active target
Check if Studio is connected and get session information
Manipulate and edit terrain
Discover the instance tree hierarchy in Workspace
Query universe and game information
Inspect UI elements or viewport information
Query and manipulate world/environment settings
No visible output schemas or return type documentation for any of the 29 tools. The rubric (Pattern: tool) requires 'Document the output schema. LLMs need to know what fields to expect so they can plan downstream tool calls.' This is a pervasive gap that breaks tool chaining and forces the LLM to guess result structure.
No error handling or recovery guidance visible in tool definitions. The rubric requires: 'Error responses must tell the LLM what to do next.' Tools like 'inspect', 'create', 'modify', 'delete', 'script_edit' perform critical operations but provide no error classification, recovery hints, or guidance on retryability.
Generic or vague tool names reduce LLM clarity. 'modify' and 'move' are ambiguous, LLMs cannot infer what modifies (all properties? specific ones?) or what move does (copy? reparent?). Per the rubric: 'The tool name alone should convey what happens when called.' Recommend 'update_instance_properties' and 'reparent_instance'.
Parameter 'op' is overloaded across multiple tools (viewport, debug, playtest, performance, console, data, terrain, world). The same parameter name implies different sets of valid sub-operations in each tool. Per the rubric: 'When multiple tools operate on the same resource, their names must make the distinction obvious.' This forces LLMs to remember different operation sets per tool. Recommend tool-specific names like 'viewport_operation', 'debug_operation', or split into separate tools.
No enum constraints on string parameters. Tools like 'execute_luau' (target: 'studio' or 'client'), 'playtest' (op: 'play'|'run'|'multiplayer'|'state'), 'inspect' (detail: 'concise'|'full') accept free-form strings without formal enum validation. Per the rubric: 'When a parameter accepts one of a known set of values, declare it as an enum. Free-form strings invite hallucinated values.'
No pagination support visible in list/discovery tools. 'tree', 'list_studios', 'inspect' likely return large hierarchies or result sets without documented limit/offset/cursor parameters or total counts. Per the rubric: 'Tools returning lists should accept page/offset and limit parameters and return a total count or next_cursor.'
Destructive tools ('delete', 'script_edit', 'modify', 'move') lack confirmation or dry-run patterns. Per the rubric: 'Irreversible operations (delete, send, publish) should support a dry-run or confirmation step. Agents make mistakes, a confirm_before_execute pattern prevents catastrophic errors.'
Sparse parameter type enforcement visible. Many tools like 'create', 'modify' describe parameters as arrays but lack detail on array element structure (e.g., what fields do objects in 'changes' array require?). Per the rubric: 'Parameters lack type definitions' cap schema at 30.