How to run Unity compile checks and tests through MCP
XUUnity MCP is designed for AI-agent loops where the closeout needs evidence: setup status, bridge health, compile validation, EditMode tests, PlayMode tests, and scene-level proof when needed.
XUUnity MCP is designed for AI-agent loops where the closeout needs evidence: setup status, bridge health, compile validation, EditMode tests, PlayMode tests, and scene-level proof when needed.
Before an agent changes a Unity project or user-level MCP config, the recommended path is to run a non-mutating setup plan. The plan should identify the Unity project, client target, helper install, manifest changes, bridge config changes, and whether the MCP client must restart or refresh afterward.
| Step | Reason |
|---|---|
setup-plan | Inspect proposed project and client mutations before approval. |
setup-apply | Apply only the approved plan to selected Unity project roots. |
validate-setup | Confirm package, bridge, helper, and client wiring state. |
ensure-ready | Bring Unity to a known editor-ready state before live checks. |
unity_status_summary | Use the first live MCP status proof after the client can see tools. |
| Compile and tests | Run compile matrix, EditMode tests, and PlayMode tests according to project risk. |
A useful AI-agent closeout should report the commands run, setup readiness, first MCP status result, compile result, test result, relevant artifacts, and whether Unity was opened by the helper and then restored. That is the difference between a generic “done” and a validation-first Unity MCP workflow.