Loading ToolBench
Structured MCP tools for Unity CLI system automation and Live Editor workflows.
Strong foundation with 13 well-structured tools, comprehensive schemas, and clear descriptions. All tools have input schemas with types and descriptions. Tool names follow verb_noun convention (unity_cli_status, unity_editor_install). Descriptions average ~120 chars, within the 10-1024 baseline. Annotations present (readOnlyHint, destructiveHint, idempotentHint). Key gaps: output schemas not documented in code; error handling lacks recovery guidance; some parameter descriptions could be more prescriptive about constraints and formats.
Build a Unity project for a target platform. Requires confirmed=true.
Read authoritative help from the installed experimental Unity CLI. Pass command segments such as ['projects','clone']; omit them for top-level help.
Forward-compatible, non-shell escape hatch for finite Unity CLI commands not covered by another tool. Adds JSON, no-banner, and non-interactive flags. Blocks server/watch modes and secret-bearing flags.
Check the Unity CLI version and optionally run its structured doctor diagnostics. Start here on an unfamiliar machine.
Preview or install a Unity Editor and optional modules. State-changing installs require confirmed=true; prefer dryRun first.
Evaluate C# code in a running Unity Editor. Arbitrary code execution; treat as local code execution risk.
Output schemas not documented. Tools return structured JSON via textResult() but LLMs cannot see the response field structure (e.g., what fields are in 'result' object). This forces LLMs to guess at downstream field names and risks broken tool chains.
Error handling lacks recovery guidance. errorResult() returns raw error messages without categorization (retryable vs fatal) or actionable next steps. LLMs cannot determine whether to retry, ask user, or abort.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 60 | 2025-06-18+ | v2 |
Send a command to a running Unity Editor or Player. Requires the Editor or Player to be running and accessible.
Check if a Unity Editor is running and accessible. Optionally target a specific project or runtime.
List, preview, or install platform modules for an existing Editor. Installs require confirmed=true and explicit EULA acceptance when applicable.
List Editor Pipeline state/versions or install/upgrade com.unity.pipeline for a project. Install and upgrade require confirmed=true.
Create a new non-interactive Unity project from a template. Requires confirmed=true because it creates files and may install an Editor.
List Hub-registered Unity projects or inspect one project, including its required Editor and module information.
Run Unity tests in a project. Supports unit tests, integration tests, and play mode tests.
Parameter descriptions lack prescriptive constraints. E.g., 'version' in unity_editor_install accepts 'lts' by default but no description explains valid formats (semantic version, 'lts', 'latest'). 'modules' array has maxItems=32 but no description of valid module names or format.
Confirmation pattern incomplete. Tools like unity_editor_install and unity_build require confirmed=true for destructive ops, but no guidance on what happens if confirmed=false (does it return a preview, error, or proceed anyway?). Ambiguous behavior invites misuse.
Tool composition risk: unity_live_command and unity_eval both target running Editors via projectPath/runtime/runtimePath, but no guidance on when to use each or how they interact. LLMs may conflate them or call both unnecessarily.