Unity Debug Profiler

Find root causes from real evidence and optimize measured bottlenecks, for casual iOS games in Unity, driven entirely through the unity-mcp-bridge (CoplayDev unity-mcp). This is the debug/profile phase of unity-game-director.

Doctrine (do not skip)

1. Evidence-driven. Read the actual console and profiler before theorizing. read_console(types=["error"]) is the first move on any "it's broken." Never guess at a cause you could have read.
2. Lean gates. Diagnose, fix the root cause in the owning script/component, verify. Don't stack confirmation prompts at every micro-step.
3. Unity 6 APIs differ from memory. The model's built-in Unity knowledge is ~2022.3. On Unity 6 (6000.x), the Input System, URP/RenderGraph, profiler, and build APIs differ. Verify any C#/shader/API you write with MCP unity_reflect (live reflection) or unity_docs before writing it. Trust order: reflection > project assets > docs > memory.
4. Verify fixes by re-running. Re-compile, re-read the console clean, enter Play Mode, screenshot. A fix is not done until the evidence is clean.

Step 0 — readiness

Read mcpforunity://editor/state and proceed only when ready_for_tools==true, is_compiling==false, is_domain_reload_pending==false. Read mcpforunity://project/info once to branch correctly: renderPipeline (URP vs Built-in shader names), activeInputHandler, UI stack. The render pipeline value is the single most common root cause of "pink materials."

Console-first debugging

Compile errors block everything — scene work, Play Mode, and tests all fail or run stale until C# compiles clean. Fix compile errors first.