Diagnosing status of unity.

[jarek108]

It seems to me it is not currently possible to check the status/readiness of the Unity. Specifically, id like to know in which of these states it is:

• working i.e. compiling/reloading scripts
• running tests
• idle

not knowing my tests are still running/scripts are building often leads to a cascade of failures on the side of the client who could just wait for the test completion/script compilation

[dsarno]

Hi there. Can you be more specific about what you're trying to do, and what errors you're getting? We just released some new features tonight so I'm trying understand if your problem is related -- when did you install the mcp?

[jarek108]

updated. it may be more stable and the consecutive MCP test calls either wait for each other or timeout. 2 problems I diagnosed:
1 minor error: if I MANUALLY run tests, the MCP call to run_tests will interfere causing false failing tests. is it possible MCP calls only check if other MCP calls are taking place instead of checking the status of the test runner directly?
2. major inconvenience. if tests are already running, run_tests (unity-mcp MCP Server) {"include_details":true,"mode":"EditMode"}
returns a timeout after few seconds:
{"success":false,"message":null,"error":"TimeoutError","data":null,"hint":"retry"}

even if I have

"unity-mcp": {
"httpUrl": "http://localhost:8080/mcp",
"timeout": 180000
}

in my .gemini\settings.json . im guessing this is a unity-side timeout im getting? how can I adjust the timeout to avoid this?

[jarek108]

regardless of the above having a check_status tool returning sth like: idle, play mode, test running, possibly sth else?? would be gold for me. your thoughts?

[dsarno]

Hi, thanks for checking and the additional info. One thing I'd like to understand better -- are you running multiple agents or Unity instances or similar? How long dos your test run take when you do it manually?

As you may know, the general principle is that a run of Unit tests essentially locks up Unity while it's running, no matter what you do. So in that sense it's correct for other calls to have to wait or even timeout if your test run is long. Unity simply isn't available to do anything else until the tests finish.

If you could help me understand what you're trying to do a bit more clearly I might be able to aside or help more. Maybe some screenshots or video? But yeah the main thing is tests just eat up Unity's main bandwidth till they're done.

[dsarno]

Also in don't believe many or any of us contributors have used Gemini cli with the mcp, so that could be lost off the issue if they don't play nice together. Other clients like cursor and Claude code are generally fine with Unity test runs

[jarek108]

ill break it down

1. 'are you running multiple agents' no, the issue I have occurs with one agent:

• agent runs tests
• detects a place that needs a fix based on tests
• fixes it fast
• before unity recovers after testing + recompiles after the change agent requests new tests
• new tests are initiated, start but timeout
• LLM starts them again (as they failed from its perspective), while they are still running in Unity
• vicious loop continuous.

if one could check unity status (idle/compiling/testing) before running the tests and wait if it is currently not ready (e.g. testing or compiling) this would be easier to avoid than via any fixed timeouts.

a partial/suboptimal solution would be to increase the timeouts aggressively. as I mentioned im doing 'timeout": 180000' on the side of client but it seems there is some timeout on the side of the unit-mcp as well as I'm still getting timeouts faster than specified, but perhaps I misunderstand this part

2. 'don't believe many or any of us contributors have used Gemini cli with the mcp, so that could be lost off the issue' I have been working like this for 2 weeks and Im happy to report that Gemini CLI works well with your MCP. The issue I have is platform independent, the same pattern appears e.g. in Antigravity when I use it.

3. ' in that sense it's correct for other calls to have to wait or even timeout if your test run is long'
   Yes, that is correct that is what I mean that now the behavior via MCP is correct - they wait for each other. but in case of the manual test run MCP initiated one seems to break it.

screenshot for normal test run:

the same project, MCP testing interrupted manual testing:

but like I say this is a minor issue, the main point is 1.

[dsarno]

@jarek108 Ok, thanks for the extra info and thoughts. I'm going to work on something that makes the mcp and Unity bridge smarter about when it's "busy" or "running tests" so we can reduce churn. Basically, right now our timeout system is dumb -- tools just try until they run out of time, and then stop. But we can tell them, "ok I hear you, but we're running tests right now, so hold off until we're done instead of spamming more run-test calls. Then when we're done you can try again". That kind of thing.

[dsarno]

@jarek108 I just pushed version 8.7.0 – – it's got a bunch of these features, so please give it a try and let me know how it works

[jarek108]

hey @dsarno thanks a lot. based on your work I wrote this script that is now my single point of debugging for the agents. ensures the proper flow with build, console check, test runs. it optionally uses this one to bring unity into focus (on my machine unity was sometimes unresponsive without this), but works without it too.

here is an example test run:

and here for example console errors force model to fix them first:

it uses your work from last commit and IMO this layer is a superior way to call the MCP, as it enforces the agents to keep the right flow, avoids running tests with console errors etc. so I use prompting like 'Testing & Diagnostics - NEVER use MCP's read_console, run_tests, or manage_scene (save) directly. ALWAYS use python tools/diagnose_unity.py' as you can see here

curious to hear your thoughts

[dsarno]

Yes that make sense.

But when your script forces Unity window to activate -- that doesn't interfere with with the agent right? It just keeps agenting, except you have to click back on Gemini to bring it to front again. Is that annoying?

[jarek108]

oh no. in my system at least (windows, did not check if/how this works for linux) this activation just ensures unity window is on top. (takes half of one of my screens) gemini/antigravity is ale the time both running and visible all the time. not only this does not interfere with the agent but also with me - im currently writing to you using my part of the screen while it codes/test in unity calling the script in its own context and taking screenshots to make sure the game looks like intended

[dsarno]

Great thanks. I like your diagnose Unity flow. Maybe will do something similar as a core mcp tool. 👍🏼👍🏼

[jarek108]

screencaptures are another thing id improve. had to use my own instead of MCP as yours is (or was in the old version I checked)
a) limited to ingame window captures while I need to see entire inspector also in edit mode (e.g. for custom editor coding)
b) sometimes unresponsive in playmode/compilation/testing

[jarek108]

Great thanks. I like your diagnose Unity flow. Maybe will do something similar as a core mcp tool. 👍🏼👍🏼

that makes a a lot of sense!

[dsarno]

I added a "nudge_unity" python utility in the test runner tool -- I didn't generalize it yet, but it's a good start toward allowing the agents to work around unity's idiosyncratic "stall" states. See #554

[dsarno]

So thanks for the inspiration @jarek108 !