Loading ToolBench
MCP server for executing Unity operations and requesting Editor information from AI MCP enabled hosts
This MCP server manages 9 tools for Unity editor automation. The tools are clearly named with action verbs (add_, execute_, get_, run_, select_, send_, update_) and have descriptions, but several lack rigor in parameter documentation and output schema clarity. Parameter types are present in the schema JSON (string, number, object, boolean, enum), but many lack detailed descriptions explaining validation constraints, ranges, or dependencies. Error handling is present in the C# code (validation_error, not_found_error, invalid_asset_type) but descriptions don't guide LLMs toward recovery. Output schemas are not explicitly documented in the tool definitions, the MCP tool registration must infer them from execution. The server supports HTTP transport with proper WebSocket fallback and includes per-request logging, placing it in the B/C range of quality.
Adds an asset from the AssetDatabase to the Unity scene
Adds packages into the Unity Package Manager
Executes a Unity menu item by path
Retrieves logs from the Unity console with pagination support to avoid token limits
Runs tests using Unity's Test Runner
Sets the selected GameObject in the Unity editor by path or instance ID
Sends a message to the Unity console
Parameter dependencies undocumented (mutual exclusivity, conditional requirements). Multiple tools (add_asset_to_scene, select_gameobject, update_component, update_gameobject) accept multiple identifier types (path + ID, assetPath + guid) but do not explicitly state mutual exclusivity or priority order in descriptions. Per the rubric, 'When one parameter's valid values depend on another, document this in both parameter descriptions.'
Generic/overloaded parameters lack type discrimination. 'update_component' and 'update_gameobject' accept generic 'componentData' and 'gameObjectData' objects without field enumeration or type schema. LLMs cannot infer valid fields. Per the rubric, 'Return structured objects with typed fields. Free-text responses require the LLM to parse unstructured output.'
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | B | 74 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 46 | - | v1 |
Updates component fields on a GameObject or adds it to the GameObject if it does not contain the component
Updates or creates a GameObject and its properties (name, tag, layer, active state, static state) based on instance ID or object path.
Output schemas not explicitly documented. Tool descriptions do not specify what fields are returned (e.g., does add_asset_to_scene return the instantiated GameObject's transform data? instance ID? hierarchy path?). Per the rubric, 'Document the output schema. LLMs need to know what fields to expect so they can plan downstream tool calls.'
Parameter descriptions lack validation constraints. Numeric parameters (position x/y/z, layer, limit, offset) lack explicit min/max ranges or units. String parameters (menuPath, objectPath, componentName) lack format constraints or enumeration guidance. Per the rubric, 'Specify minimum and maximum for numeric parameters. When a parameter has a regex pattern, length limit, or character restriction, state it in the description.'
Error recovery guidance incomplete. Code implements error responses (validation_error, not_found_error, invalid_asset_type) but tool descriptions do not guide LLMs on what to do next. Per the rubric, 'Error responses must tell the LLM what to do next: "User not found. Try search_users() with a partial name." A raw error code or stack trace gives the agent nothing to act on.'
No confirmation or dry-run support for destructive operations. Tools like update_gameobject (isActiveSelf can deactivate objects) and update_component (can remove components) are marked WRITE but lack a dry-run or confirmation step. 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.'