initialization timeout

[tribbloid]

observed on Ubuntu 24.04, V6.3, python 3.11, VSCode native MCP list_tools

2025-10-30 18:35:02.144 [info] Connection state: Starting
2025-10-30 18:35:02.144 [info] Connection state: Running
2025-10-30 18:35:02.447 [warning] [server stderr] 2025-10-30 18:35:02,446 - unity-mcp-server - INFO - Unity MCP Server starting up
2025-10-30 18:35:02.447 [warning] [server stderr] 2025-10-30 18:35:02,446 - unity-mcp-server - INFO - Creating new Unity connection
2025-10-30 18:35:02.447 [warning] [server stderr] 2025-10-30 18:35:02,446 - unity-mcp-server - INFO - Connected to Unity at localhost:6400
2025-10-30 18:35:07.144 [info] Waiting for server to respond to `initialize` request...
2025-10-30 18:35:12.144 [info] Waiting for server to respond to `initialize` request...
2025-10-30 18:35:17.144 [info] Waiting for server to respond to `initialize` request...
2025-10-30 18:35:22.144 [info] Waiting for server to respond to `initialize` request...
2025-10-30 18:35:27.144 [info] Waiting for server to respond to `initialize` request...
2025-10-30 18:35:32.145 [info] Waiting for server to respond to `initialize` request...
2025-10-30 18:35:37.145 [info] Waiting for server to respond to `initialize` request...
2025-10-30 18:35:42.144 [info] Waiting for server to respond to `initialize` request...
2025-10-30 18:35:47.144 [info] Waiting for server to respond to `initialize` request...
2025-10-30 18:35:52.144 [info] Waiting for server to respond to `initialize` request...
2025-10-30 18:35:57.144 [info] Waiting for server to respond to `initialize` request...

no traceback available.

any ideas? I haven't used it since the migration

[tribbloid]

upon investigation the cause seem trivial:

when the first agent setup a stdio channel and quit, it closes the stdio stream. This should detach the client process and cause it to terminate

But it doesn't, so the process stay there to hog the port.

I wonder if it's a lot of work to implement the following:

1. When setting up the server, use a random port (probably by hashing the working directory)
2. When running the client python code, scan ports or working directory and negotiate for a long-running RPC
3. client should exit upon stdio detach

Thanks for your attention! You are doing great work. The fundamental cause is just a MCP protocol design flaw, they should start with disk/memory IO instead of port/stdIO first

[dsarno]

I tried to work around this with a signal handler system (#363), and it fixed the issue for me, but a user reported a connection fail after I merged it, so I reverted for now.

[tribbloid]

is there a ticket for the connection fail after that patch? It may just happen randomly (like any RPC server) and not caused by process termination.

a circumvention would be to use a random port based on project path & port assignment, this also makes multiple Unity Editors controllable.

[dsarno]

@tribbloid Here's what they saw after my patch

logs:

2025-11-01T15:24:04.673Z [unityMCP] [info] Server transport closed { metadata: undefined }
2025-11-01T15:24:04.673Z [unityMCP] [info] Client transport closed { metadata: undefined }
2025-11-01T15:24:04.673Z [unityMCP] [info] Server transport closed unexpectedly, this is likely due to the process exiting early. If you are developing this MCP server you can add output to stderr (i.e. `console.error('...')` in JavaScript, `print('...', file=sys.stderr)` in python) and it will appear in this log. { metadata: undefined }
2025-11-01T15:24:04.673Z [unityMCP] [error] Server disconnected. For troubleshooting guidance, please visit our [debugging documentation](https://modelcontextprotocol.io/docs/tools/debugging) { metadata: { context: 'connection', stack: undefined } }
2025-11-01T15:24:04.674Z [unityMCP] [info] Client transport closed { metadata: undefined }

[tribbloid]

I have consulted the design of Scala LSP MCP, their solution is to let the server generate a short configuration file (e.g. under ./.unityMCP) that contains a random port number, make it visible to the client, and if the port is occupied, terminate the process that hog it after a short delay.

Though I don't know if this conflict is from client (in python, as shown in your PR) or from the server. I'm under impression that multiple clients can subscribe to the same http-sse port, in which case it must be from the server (in C#, using resource management of Unity's vanilla lifecycle management). Do you know the answer or how to figure it out?

[msanatan]

Hey hey, I'm doing some general network improvements, that should allow for users to configure their own ports (it's not editable, but that's why they were put in the settings of the UI). Hopefully I'm able to fix other issues as well