Loading ToolBench
Open-source AI agent toolkit for building, inspecting, testing, and automating Roblox games in Studio.
BloxForge has 33 tools with comprehensive Rojo, toolchain, and quality analysis capabilities. All tools have descriptions and input schemas are explicitly defined with types. However, there are consistent gaps in output schema documentation, parameter descriptions could be more detailed with constraints, and error handling guidance is minimal. The tool names follow verb_noun patterns well (detect_, get_, validate_, serve_, build_, etc.), but several tools lack specific constraints like enums or ranges. Per-tool analysis shows an average of 65/100 due to these pattern deviations.
Build a Rojo project to generate a Roblox place or model file.
Create a new source file in the project.
Delete a source file from the project.
Detect and locate Roblox projects in the file system, searching for project files (rojo.json, sourcemap.json, etc.) and available tools.
Preview formatted Lua/Luau code using stylua without writing to disk.
Generate a sourcemap.json file that maps Rojo source files to their corresponding Roblox instances.
Get information about a specific Roblox project including project file location, root directory, and configuration.
Get the installed version of Rojo and its capabilities.
Output schemas not documented. No tool definition shows what fields are returned, forcing LLMs to guess at response structure and complicating downstream tool chaining.
Numeric parameters lack ranges. 'limit' in serve_logs and 'port' in serve_start have no min/max bounds. LLMs could pass absurd values (port=999999, limit=-1) that cause failures.
No error handling guidance in descriptions. Destructive tools (delete_source, patch_source, native_syncback_apply) and write tools (build_project, rokit_install) lack recovery hints or error classification.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 56 | 2026-07-28+ | v2 |
Apply a syncback plan to merge changes from a place file into source code.
Generate a plan for syncing changes from a Roblox place file back to source code.
Apply a patch to a source file using old text and new text with hash validation.
Read the contents of a Rojo source file.
Resolve the source file path for a given Roblox instance path using the sourcemap.
Resolve the source file location for a Roblox instance by parsing sourcemap.json.
Resolve the instance path for a given source file using the sourcemap.
Detect and identify the installed Rokit or Aftman toolchain configuration.
Read and parse the rokit.toml or aftman.toml manifest without modifying it.
Install or update tools declared in the rokit.toml or aftman.toml manifest.
List all tools installed via Rokit or Aftman.
Report the status of Rokit/Aftman tools, comparing manifest pins, installed shims, and running versions.
Retrieve logs from an active Rojo serve session.
Start a Rojo serve session to sync code changes to Roblox Studio in real-time.
Get the current status of an active Rojo serve session.
Stop an active Rojo serve session.
Validate a Rojo project by performing a test build to check for errors.
Validate Lua/Luau script source code using multiple quality tools (luau-analyze, selene, stylua).
Generate a dependency graph from the wally.lock file.
Read and parse the wally.lock file to get resolved dependencies.
Read and parse the wally.toml manifest file.
Install or update dependencies declared in wally.toml.
List Wally packages that have newer versions available.
Search the Wally package registry.
Validate that all dependencies in wally.lock satisfy the requirements in wally.toml.
Confirmation/dry-run patterns incomplete. delete_source offers 'confirm' and 'dryRun' parameters, but other destructive tools lack them. patch_source and native_syncback_apply should support dry-run mode.
Parameter descriptions lack constraint details. 'sourcePath' in read_source, patch_source, etc. has no guidance on path format (relative? absolute? separators?). LLMs will guess, causing path lookup failures.
Mutual exclusivity not documented. serve_start accepts both 'root' and 'projectFile' as optional, but their interaction is unclear. Does one override the other? Are both needed?