Model Context Protocol server for Unity Editor automation and project management via IPC communication
Server has 12 tools with explicit schemas and descriptions, but quality is inconsistent. Tool names lack action verbs (unityctl_* prefix obscures intent). Descriptions are present but generic (avg ~60 chars, below 194-char baseline). Parameters have types and descriptions, but many lack constraints (enums, ranges). Output schemas are not documented. Error handling is minimal, responses are JSON-serialized but lack recovery guidance. No tool annotations (readOnlyHint/destructiveHint). Composition is reasonable (single responsibility per tool), but parameter naming could be clearer (e.g., 'type' in CheckTool is ambiguous).
Build project for target platform
Check script compilation status
Execute C# expression in Unity Editor
Query flight recorder logs
Check connectivity to Unity Editor
Query Unity Editor state (use unityctl_schema for params)
Execute write/action command (use unityctl_schema for params)
Tool names lack action verbs. All tools prefixed with 'unityctl_' (unityctl_build, unityctl_exec, unityctl_query) obscure intent. LLMs cannot infer action from name alone, 'unityctl_query' could mean read, search, or discover. Should be verb_noun: 'query_editor_state', 'execute_code', 'build_project'.
Output schemas not documented. Tools return JSON-serialized CommandResponse or FlightEntry objects, but LLMs cannot see the field structure. No documentation of what fields to expect (e.g., does CommandResponse contain 'status', 'data', 'error'?). Agents cannot plan downstream calls or extract data reliably.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 51 | 2026-07-28+ | v2 |
Command schema discovery (filter by command or category)
List active and recent sessions
Editor and project compilation status
Run Unity tests (edit/play mode)
Collect real-time editor events (poll mode)
Missing tool annotations. No readOnlyHint, destructiveHint, or idempotentHint attributes. Agents cannot distinguish safe (read-only) tools from destructive ones (build, exec, run). This prevents safe retry logic and increases risk of accidental side effects.
Ambiguous parameter names. 'type' in unityctl_check, 'op' in unityctl_log, 'command' in unityctl_run and unityctl_query are vague. 'type' could mean data type, check type, or resource type. 'op' is cryptic (operation?). Descriptions help but names should be self-documenting.
Missing enum constraints. 'target' in unityctl_build lists valid values in description ('StandaloneWindows64, OSX, Linux, Android, iOS, WebGL') but not as enum schema. 'mode' in unityctl_test ('edit or play') and 'channel' in unityctl_watch ('console, hierarchy, compilation, all') should be enums. Free-form strings invite hallucinated values.