unity-drivinglisted

# Driving a Unity game over SDB The `unity` tools drive a running Unity Mono development build over the Mono Soft Debugger protocol (SDB); this skill is the field-verified procedure the tool schemas cannot carry. Everything holds for any dev-Mono Unity game; game-specific facts are labeled (verified on Cities: Skylines II, "CS2"). A retail build exposes no SDB port; only a development Mono build is drivable. ## Session lifecycle There is no attach tool: the first tool that needs the VM attaches lazily, the session persists, and a dropped connection reattaches on the next call, so just call the tool you need. `status` is the read-only orient step: candidate processes with their SDB port, plus session state (attached, held suspensions). The SDB port drifts between game runs; discovery re-resolves it on every (re)attach, so a game restart costs nothing. Discovery that finds several candidates fails with the list; narrow with the process-name prefix or the `UNITY_MCP_PROCESS` / `UNITY_MCP_PORT` env config. The debugger slot is exclusive: while attached, an IDE debugger (Rider/dnSpy/VS) cannot attach to the game, and vice versa; `detach` frees the slot, and the next unity call reattaches on its own. An attach failure while an IDE holds the slot looks like a connection refusal, not "slot taken". ## Suspend windows Between calls the game runs; each operation freezes it briefly around itself, so single reads and writes need no ceremony. When several calls must see one consistent